Kerberos認証への攻撃をログ分析の観点で理解してみる

今回は、Windows Active Directory環境で多くの企業が採用しているKerberos認証のセキュリティとして、SIEM製品の一つである Splunk を使って検知する方法について調べていこうと思います。

Splunkはセキュリティ分野でのナレッジが非常に多く、たくさんのブログや分析ストーリーなどのコンテンツが公開されています。

今回は、こちらの記事を基に、いくつかの攻撃についてピックアップしながら、攻撃の仕組みとSIEMでの検知方法、攻撃に対する軽減措置について調べていこうと思います。

Kerberos認証の仕組み

まずはじめに、Kerberosの攻撃を理解するには、Kerberos認証の仕組みを理解する必要があります。
Kerberos認証で使われるいくつかの用語があるのでまず確認します。

用語

用語	説明
KDC	Key Distribution Center - 認証サーバ チケットを発行する役割 AD環境ではDCがKDCを担う
TGT	Ticket Granting Ticket - KDCが発行可能 利用者が本人であることを証明するためのもの
TGS	Ticket Granting Service - KDCが発行可能 サービスを利用するときに必要となるチケット
UPN	User Principle Name - サービスを利用する側
SPN	Service Principle Name - サービスを提供する側
PAC	Privileged Attribute Certificate - セキュリティ識別子 ユーザー情報など

Kerberos認証コンセプト

ここでKerberos認証のコンセプトについても少し触れておきます。
クライアントAとサービスBが安全な通信を行いたい時に、もちろん認証が必要だと考えます。
当事者間での認証では、クライアントAとサービスBがそれぞれにユーザー情報を認識し、同じ鍵を所有することで安全な認証と通信が可能となります。
しかし、ユーザーやコンピュータが多数存在する大規模な環境ではどうでしょう。それぞれがユーザー情報や認証のための鍵を共有することは管理上や運用コストを考えると難しいことが想像できます。
そこで第三者CがクライアントAとサービスBから信頼される認証サーバーとして登場します。
クライアントAは第三者Cに認証され、サービスBにクライアントAが本当にクライアントAであることを証明します。また第三者CはクライアントAにサービスBが本当にサービスBであることを証明します。
クライアントAとサービスBはお互いのことを全く意識することなく安全に認証しサービスを利用する/させることができるようになります。
これがKerberos認証のコンセプトになります。

Kerberos認証で使える暗号アルゴリズム

Kerberos認証では、認証情報をやりとりする際の暗号アルゴリズムを選択することが可能になっています。
利用可能な暗号アルゴリズムの一覧は以下になります。

暗号アルゴリズム	サポートしているOS
AES256_HMAC_SHA1	Windows Vista / Windows Server 2008以降、Windows Server 2003以前は未サポート
AES128_HMAC_SHA1	Windows Vista / Windows Server 2008以降、Windows Server 2003以前は未サポート
RC4_HMAC_MD5	Windows 2000 Server以降
DES_CBC_MD5	Windows 2000 Server以降、Windows 7 / Windows Server 2008R2以降は無効化
DES_CBC_CRC	Windows 2000 Server以降、Windows 7 / Windows Server 2008R2以降は無効化

RC4およびDESについては、複数の脆弱性が確認されているためCRYPTRECなどでも非推奨の暗号アルゴリズムとなっています。

一覧にある通りKerberos認証において、DESはWindows Server 2008R2以降のOSで無効化されているため使えませんが、RC4は利用することが可能となっています。
割と最近のOSについてはデフォルトでAESの暗号化が選択されるようになっています。

Kerberos認証の通信シーケンス

それでは、このコンセプトを踏まえた上でKerberosの通信シーケンスを見ていきます。

==== シーケンスのステップ説明 =====

1.　入力したパスワードを元に生成したKeyでタイムスタンプを暗号し（事前認証）送信
2-1.　KDCに保存されているUPNのKeyで事前認証を復号（復号可=UPNが正しいことを証明）
2-2.　KDCはユーザー情報（PAC）などを含めTGTを作成
2-3.　TGTの一部をKDCのサービスアカウント（KRBTGT）のKeyを使い暗号化、さらに一部をUPNのKeyで暗号化
3.　TGTの一部をUPNのKeyで復号（復号可=KDCが正しいことを証明）
4.　SPNへアクセスするためのTGSを要求
5-1.　TGTを復号後（復号可=TGTが正統であることを証明）、TGSを作成
5-2.　TGSはSPNのサービスアカウントのKeyで暗号化
6.　アクセスを要求
7.　TGSをSPNのサービスアカウントのKeyで復号（復号可=UPNが正しいことを証明）

===============================

※Keyは選択された暗号化アルゴリズムを使って暗号化されます。

Kerberos認証に対する攻撃

前述の通りKerberosは、Windows Active Directory環境で使われている認証方法であるため、多くの攻撃者からの標的となり、様々な攻撃手法が開発されてきました。
そのため、数多くの攻撃手段が存在しています。
その中でも広く利用される以下について見ていきます。

• Pass-the-Hash
• Overpass-the-Hash
• Pass-the-Ticket
• Golden Tickets
• Silver Tickets

Pass-the-Hash

Windowsでは、認証の際にパスワードをMD5でハッシュ化してSAM(Security Account Manager)やLSASSプロセスの利用するメモリ空間に保存またはキャッシュします。
保存されたパスワードのハッシュはローカル認証などで利用される（レガシーなWindows認証であるNTLM認証と呼ばれる）ため、こういったKerberos認証を利用できない環境での下位互換性を持った認証として使われます。
Pass-the-Hashは、MimikatzやRubeusなどのハッキングツールによって抽出され、取り出されたNTLMハッシュを認証情報として悪用します。

Pass-the-Hashは、NTLM認証の脆弱性をついた攻撃になりますが、Kerberosの下位互換のためKerberos認証への攻撃にもその技術が応用されますのでおさえておく必要があります。

Overpass-the-Hash

前に記載したようにKerberos認証では、「RC4_HMAC_MD5」の暗号アルゴリズムを要求することができます。
この暗号アルゴリズムを使って生成されたKeyには、NTLM認証で使われるハッシュ値と同じものが含まれています。
Overpass-the-Hashでは、Pass-the-Hashと同じようにSAMやLSASSプロセス内のNTLMハッシュを抽出した後、Kerberos認証の認証セッションを最初から開始し、RC4の暗号アルゴリズムを要求することで、NTLMハッシュをそのまま悪用することができます。
MimikatzやRubeusなどのハッキングツールは、ローカルコンピュータ内のNTLMハッシュを抜き取ることができ、現在のログインセッションのセキュリティコンテキストに差し込むことができます。
コンピュータの管理者権限を持ったアカウントがMimikatzなどを使うことにより、コンピュータ内にストアされている全てのアカウントのNTLMハッシュを悪用することで、ドメイン内のより高い権限を取得します。

SIEM製品で検知・分析するにはどうするか

Splunkのこちらの検知例について見ていきます。

https://research.splunk.com/endpoint/c91a0852-9fbb-11ec-af44-acde48001122/

Kerberos認証では、クライアントは認証ためにポート88へのアウトバウンド通信を行います。
通常のKerberos認証で88番ポートへのアウトバウンド通信を行うのは、LSASSプロセスのみとなります。
不審なプロセスからこのポートを使った通信が行われていないかを検出することで、Overpass-the-Hash攻撃を監視します。

[Splunkでのサーチ文]

| tstats `security_content_summariesonly` count FROM datamodel=Endpoint.Processes where Processes.process_name!=lsass.exe by _time Processes.process_id Processes.process_name Processes.dest Processes.process_path Processes.process Processes.parent_process_name 
| `drop_dm_object_name(Processes)` 
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)` 
| join  process_id dest [
| tstats `security_content_summariesonly` count FROM datamodel=Network_Traffic.All_Traffic where All_Traffic.dest_port = 88 by All_Traffic.src All_Traffic.process_id  All_Traffic.dest_port 
| `drop_dm_object_name(All_Traffic)` 
| rename src as dest ] 
|  table _time dest parent_process_name process_name process_path process process_id dest_port 
| `unknown_process_using_the_kerberos_protocol_filter`

バックスラッシュ部分はSplunkでいうマクロ関数になっていて、Settings > Advance search > Search macro で設定ができます。
設定する定義はこちらにもあるので、これを使って登録することも可能です。

---

さらにSplunkのこちらの検知例も見ていきます。

https://research.splunk.com/endpoint/18916468-9c04-11ec-bdc6-acde48001122/

Kerberos認証では、Windows 2000 Server以前の極端に古いOSを除くとRC4, AES128, AES256のアルゴリズムをサポートしています。
RC4は弱い暗号化プロトコルとして知られていますが、Windowsシステムの下位互換のためKerberos認証においては、デフォルトで無効なプロトコルとなっていません。
RC4で暗号化されたキーには、SAMやLSASSプロセスから窃取したNTLMハッシュと同等なものが含まれます。
攻撃者は暗号化プロトコルをRC4に指定してTGTを要求することで、手に入れたNTLMハッシュを使ってKerberos認証のプロセスを最初から正常に進めることが可能になります。
下位互換性があるとはいえ、RC4での認証要求は通常発生しないため、Overpass-the-Hash攻撃の疑いがあるイベントの発生がないか監視します。

[Splunkでのサーチ文]

 `wineventlog_security` EventCode=4768 Ticket_Encryption_Type=0x17 Account_Name!=*$ 
| stats count min(_time) as firstTime max(_time) as lastTime by Account_Name Client_Address dest 
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)` 
| `kerberos_tgt_request_using_rc4_encryption_filter`

その他の軽減措置や予防対策

以下のような軽減措置や予防対策も有効ですので、セキュリティ設定を見直し、セキュリティ強化の検討に加えてください。

• 通常のパソコンでアドミン権限ユーザーでのログオンを行わない
• 特権権限を持っているアカウントをレビューする（必要以上に高い権限は持たせない。ユーザーアカウントは必須だが、サービスアカウントもレビューを行う）
• パスワードは十分に長く複雑なものを使う（Microsoft LAPSなどを活用する）
• グループポリシーを活用して、ローカルアドミン権限でのログオン手段を制限して適切なグループに割り当てる（RDP経由のローカルアドミンログオンの禁止、ローカルアドミン権限でのログオン禁止など）

Pass-the-Ticket

Pass-the-TicketはOverpass-the-Hashと似ていますが、LSASSプロセスが利用しているメモリ領域からTGTを抜き出し、認証シーケンスの④から行うことで認証をバイパスします。
ローカル管理者権限でのMimikatzなどの攻撃ツールを実行されることにより、コンピュータ上に保持されたTGTを使い他のアカウントの権限を悪用し、権限昇格やネットワーク内の水平移動につなげていきます。

SIEM製品で検知・分析するにはどうするか

Splunkのこちらの検知例について見ていきます。

https://research.splunk.com/endpoint/13bbd574-83ac-11ec-99d4-acde48001122/

Windows SysInternalのシステムモニターツール「Sysmon」で取得可能なログに、Mimikatz（Pass-the−Ticketのオプション）の実行がイベント内に出力されたことを検知します。
（SysmonはMicrosoftのサイトからダウンロードすることができ、インストールするとプロセスの実行記録などWindowsシステムの詳細なログを出力することができます。）

[Splunkでのサーチ文]

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where (Processes.process = "*sekurlsa::tickets /export*" OR Processes.process = "*kerberos::ptt*") by Processes.dest Processes.user Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id Processes.parent_process_name 
| `drop_dm_object_name(Processes)` 
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)` 
| `mimikatz_passtheticket_commandline_parameters_filter`

---

さらにSplunkのこちらの検知例も見ていきます。

https://research.splunk.com/endpoint/5ed8c50a-8869-11ec-876f-acde48001122/

Mimikatzと同様の機能を持つ攻撃ツールである Rubeus の実行を、Sysmonのログイベントから検知します。
Rubeusはメモリからチケットを窃取するために特権権限でwinlogon.exeを呼び出すので、そのイベントが監視できるようにSIEMでクエリを実行します。

[Splunkでのサーチ文]

`sysmon` EventCode=10 TargetImage=C:\\Windows\\system32\\winlogon.exe (GrantedAccess=0x1f3fff) (SourceImage!=C:\\Windows\\system32\\svchost.exe AND SourceImage!=C:\\Windows\\system32\\lsass.exe AND SourceImage!=C:\\Windows\\system32\\LogonUI.exe AND SourceImage!=C:\\Windows\\system32\\smss.exe AND SourceImage!=C:\\Windows\\system32\\wbem\\wmiprvse.exe) 
| stats count min(_time) as firstTime max(_time) as lastTime by dest, SourceImage, SourceProcessId, TargetImage, TargetProcessId, EventCode, GrantedAccess  
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)` 
| `rubeus_kerberos_ticket_exports_through_winlogon_access_filter`

---

さらにSplunkのこちらの検知例も見ていきます。

https://research.splunk.com/endpoint/cca37478-8377-11ec-b59a-acde48001122/

同じくRubeusで実行されるコマンドラインのオプションがSysmonのログイベントに出力されていないかを検知します。

[Splunkでのサーチ文]

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where (Processes.process = "*ptt /ticket*" OR Processes.process = "* monitor /interval*" OR Processes.process ="* asktgt* /user:*" OR Processes.process ="* asktgs* /service:*" OR Processes.process ="* golden* /user:*" OR Processes.process ="* silver* /service:*" OR Processes.process ="* kerberoast*" OR Processes.process ="* asreproast*" OR Processes.process = "* renew* /ticket:*" OR Processes.process = "* brute* /password:*" OR Processes.process = "* brute* /passwords:*" OR Processes.process ="* harvest*") by Processes.dest Processes.user Processes.parent_process Processes.process_name Processes.process Processes.process_id Processes.parent_process_id Processes.parent_process_name 
| `drop_dm_object_name(Processes)` 
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)` 
| `rubeus_command_line_parameters_filter`

Golden Tickets

TGTは、ユーザーが存在しパスワード認証が成功したことを証明するためのチケットで、唯一KDCが発行できるものです。
Golden Ticketsは任意のユーザーのTGTを偽造し、Kerberos認証シーケンスの④からはじめることで認証をバイパスします。
任意のユーザーのTGTの偽造が可能なので、事実上全てのサービスへの権限を取得することが可能になります。
通常のKerberos認証において、KDCはTGTを生成する際にKDCのサービスアカウントであるKRBTGTのキーを使って暗号・署名を行います。
攻撃者はKRBTGTのNTLMハッシュを窃取し、TGTを偽造します。

SIEM製品で検知・分析するにはどうするか

Splunkのこちらの検知例について見ていきます。

https://research.splunk.com/endpoint/7d90f334-a482-11ec-908c-acde48001122/

Golden TicketsのTGT偽造後の次の攻撃ステップであるRC4暗号アルゴリズムでのTGS要求を検知します。

[Splunkでのサーチ文]

`wineventlog_security` EventCode=4769 Service_Name="*$" (Ticket_Options=0x40810000 OR Ticket_Options=0x40800000 OR Ticket_Options=0x40810010) Ticket_Encryption_Type=0x17 
| stats count min(_time) as firstTime max(_time) as lastTime by dest, service, service_id, Ticket_Encryption_Type, Ticket_Options 
| `security_content_ctime(lastTime)` 
| `security_content_ctime(firstTime)` 
| `kerberos_service_ticket_request_using_rc4_encryption_filter`

Silver Tickets

Silver TicketsはGolden Ticketsと対照に、TGSを偽造する攻撃になります。
Golden Ticketsは全てのサービスの権限を取得できますが、Silver Ticketsでは偽造したチケットでアクセス可能な特定のサービス（SPN）の権限が対象となります。
また、TGSはサービス（SPN）のキーで暗号・署名されているため、攻撃者はSPNのキーを窃取する必要があります。
SPNのローカルSAMアカウントから抜き取ったり、あるいはKerberoastingというハッキングを利用することでNTLMハッシュを盗みとります。
その後、MimikatzやRubeusなどのツールでTGSを偽造することが可能になります。
Silver Ticketsは、一度SPNのNTLMハッシュを取得することができると、KDCとの通信のやりとりは一切行わずとも、UPNとSPN間でのみの通信だけで権限を得ることができるため、KDCにログが残らず、検知が困難になる特徴があります。

SIEM製品で検知・分析するにはどうするか

Splunkのこちらの検知例について見ていきます。

https://research.splunk.com/endpoint/13243068-2d38-11ec-8908-acde48001122/

TGSの偽造には、SPNのNTLMハッシュが必要となります。
攻撃者はPowershellを使って、Kerberosチケットを要求することで自分のメモリにTGSをキャッシュしようとします。

[Splunkでのサーチ文]

`powershell` EventCode=4104 ScriptBlockText="*KerberosRequestorSecurityToken*" 
| stats count min(_time) as firstTime max(_time) as lastTime by ScriptBlockText Opcode Computer UserID EventCode 
| rename Computer as dest 
| rename UserID as user 
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)` 
| `serviceprincipalnames_discovery_with_powershell_filter`

---

さらにSplunkのこちらの検知例も見ていきます。

https://research.splunk.com/endpoint/eb3e6702-8936-11ec-98fe-acde48001122/

攻撃者はターゲットとなるSPNのNTLMハッシュを含むTGSを可能な限り多く要求し、KerberoastingまたはSilver Tickets攻撃に利用しようとします。
RC4のTGS要求のイベントを監視することで、Silver Ticketsの攻撃準備を行っていることを検知します。
RC4のTGS要求イベントは環境によって、False Positiveが発生することも多いため、通常より要求数が多い場合にアラートとするアノマリー検知として工夫することも効果的です。

[Splunkでのサーチ文]

 `wineventlog_security` EventCode=4769 Service_Name!="*$" Ticket_Encryption_Type=0x17 
| bucket span=2m _time 
| stats dc(Service_Name) AS unique_services values(Service_Name) as requested_services by _time, Client_Address 
| eventstats avg(unique_services) as comp_avg , stdev(unique_services) as comp_std by Client_Address 
| eval upperBound=(comp_avg+comp_std*3) 
| eval isOutlier=if(unique_services > 2 and unique_services >= upperBound, 1, 0) 
| search isOutlier=1 
| `unusual_number_of_kerberos_service_tickets_requested_filter`

まとめ

以上、Kerberos認証において、認証情報を奪取するための代表的な攻撃例と検知方法について調べてみました。
Kerberos認証はシングルサインオンが可能な認証としてよく知られ、動きも複雑なので、攻撃方法と検知方法を理解するために基本的な認証シーケンスを理解することは大切だと感じました。
Kerberos認証への攻撃は他にもあり、バリエーションも豊富なので、また次回ブログにしていきたいと思います。